Brutal Address Space Layout Randomisation
roy g biv / defjam
<![CDATA[
Brutal Address Space Layout Randomisation
roy g biv / defjam
-= defjam =-
since 1992
bringing you the viruses of tomorrow
today!
Former DOS/Win16 virus writer, author of several virus families, including
Ginger (see Coderz #1 zine for terrible buggy example, contact me for better
sources ;), and Virus Bulletin 9/95 for a description of what they called
Rainbow. Co-author of world's first virus using circular partition trick
(Orsam, coded with Prototype in 1993). Designer of world's first XMS swapping
virus (John Galt, coded by RT Fishel in 1995, only 30 bytes stub, the rest is
swapped out). Author of world's first virus using Thread Local Storage for
replication (Shrug, see Virus Bulletin 6/02 for a description, but they call
it Chiton), world's first virus using Visual Basic 5/6 language extensions for
replication (OU812), world's first Native executable virus (Chthon), world's
first virus using process co-operation to prevent termination (Gemini, see
Virus Bulletin 9/02 for a description), world's first virus using polymorphic
SMTP headers (JunkMail, see Virus Bulletin 11/02 for a description), world's
first viruses that can convert any data files to infectable objects (Pretext),
world's first 32/64-bit parasitic EPO .NET virus (Croissant, see Virus
Bulletin 11/04 for a description, but they call it Impanate), world's first
virus using self-executing HTML (JunkHTMaiL, see Virus Bulletin 7/03 for a
description), world's first virus for Win64 on Intel Itanium (Shrug, see Virus
Bulletin 6/04 for a description, but they call it Rugrat), world's first virus
for Win64 on AMD AMD64 (Shrug), world's first cross-infecting virus for Intel
IA32 and AMD AMD64 (Shrug), world's first viruses that infect Office
applications and script files using the same code (Macaroni, see Virus
Bulletin 11/05 for a description, but they call it Macar), world's first
viruses that can infect both VBS and JScript using the same code (ACDC, see
Virus Bulletin 11/05 for a description, but they call it Cada), world's first
virus that can infect CHM files (Charm, see Virus Bulletin 10/06 for a
description, but they call it Chamb), world's first IDA plugin virus (Hidan,
see Virus Bulletin 3/07 for a description), world's first viruses that use the
Microsoft Script Encoder to dynamically encrypt the virus body (Screed),
world's first virus for StarOffice and OpenOffice (Starbucks), world's first
virus IDC virus (ID10TiC), world's first polymorphic virus for Win64 on AMD
AMD64 (Boundary, see Virus Bulletin 12/06 for a description, but they call it
Bounds), world's first virus that can infect Intel-format and PowerPC-format
Mach-O files (MachoMan, see Virus Bulletin 01/07 for a description, but
they call it Macarena), world's first virus that uses Unicode escapes to
dynamically encrypt the virus body, world's first self-executing PIF (Spiffy),
world's first self-executing LNK (WeakLNK), world's first virus that uses
virtual code (Relock), world's first virus to use FSAVE for instruction
reordering (Mimix). Author of various retrovirus articles (eg see Vlad #7 for
the strings that make your code invisible to TBScan). This is a tool to
prevent dumping of a process. It is sad that this intro is longer than the
text, but I have been busy. :)
What is it?
Other Address Space Layout Randomisation implentations require that a file has
relocations, so that the sections can be moved to new locations in memory.
My Address Space Layout Randomisation does not require that a file has
relocations. I call this "brutal" because of how it works - it makes a copy
of the host process memory in a different location, and marks the old host
process memory as NO_ACCESS. Then it redirects all accesses when a page fault
occurs. The redirection is to a place in memory that is allocated "randomly".
The new place in memory is whatever is returned by VirtualAlloc(), but the
allocation size is randomly increased a little bit so that the areas are not
sequential in memory. They are also allocated in reverse order. The
performance is bad if the process accesses a lot of its own memory locations
but the technique is effective and that is the most important thing.
What technique?
Simply that a protected process cannot be dumped using ordinary tools.
Why not?
ReadProcessMemory() cannot access the page because the page is not accessible,
and the protection has no chance to intercept the request. Even an injected
thread or DLL cannot dump easily - that code would have to copy the bytes in
each page to another location, because WriteFile() cannot be used directly.
There are some limitations, though. The first limitation is that code cannot
move relatively between sections. This means no relative call/jmp/branch
across section boundaries. This breaks packers like UPX which use a relative
jump to the host entrypoint. If you want to pack first, then use something
like PECompact instead, or any packer that uses push/ret to move around.
The second limitation is that it cannot handle any SSSE3 (SSE4) instructions,
because they use a different format from all other instructions (0f, major
byte, minor byte, then modr/m byte), and my length-disassembler code does not
understand that.
The third limitation is that you cannot use any APIs that pass ring 3 buffers
into ring 0, if the ring 3 buffer is inside the image. This means that you
cannot use for example VirtualQuery() or WriteProcessMemory() unless you put
the data on the stack or heap first. You also cannot use LoadIcon() from the
resources, so no GUI applications can be protected.
The tool assumes that you know what you are doing. ;) It assumes that the
file is a Portable Executable and not a DLL. Appended data are not preserved.
The checksum is set to zero. The code requires Unicode support, so it is only
for Windows NT and later. The protection cannot run on Windows 9x/Me, anyway.
Greets to friendly people (A-Z):
Active - Benny - izee - Malum - Obleak - Prototype - Ratter - Ronin -
RT Fishel - sars - SPTH - The Gingerbread Man - Ultras - uNdErX - Vallez -
Vecna - VirusBuster - Whitehead
rgb/dj feb 2008
iam_rgb@hotmail.com
]]>